Analysis

• Thanks Emma.
• We’ve now provided an overview of the first three steps of a script-based workflow: project setup, data wrangling and data preservation. I’ll now cover data analysis.

Analysis

Criteria for Best Practice

• The steps are clear
• The workflow is reproducible
• Limited opportunities for human error

• Every ecological data analysis is unique, so it would be challenging to provide a workflow that works in all situations.
• That said, there are some criteria that can be applied to evaluate whether a workflow is following best practices
• In general, the step of an analysis should be clear. Not only to future you but to others that might want to better understand the tools and decisions made related to how you performed an analysis.
• Similarly, the analysis should be reproducible. At a minimum, the steps should be documented, but ideally, someone should be able to pick up your work and reproduce it without any additional tools or knowledge.
• Finally, we should strive to limit introducing human error into an analysis. Much of this originates from steps in processing the data just prior to analysis.

Analysis: Manual Workflow

Steps

1. Reformat observation data
2. Get spatial covariates
3. Load data into software (PRESENCE, Mark, Distance, etc.)
4. Use interface to select options
5. Run it and export results

• In a traditional manual workflow, the analytical steps might look something like this. [click]
• First, observation data are reformated. This might be done by copying the raw data into another Excel tab and moving columns, calculating values, or pivoting the structure of the spreadsheet. [click]
• Second, spatial covariates are often needed. To get these, one might go online to a GIS data repository, download the data, and load these into a GIS software like ArcGIS Pro. Or better, one might get the data into ArcGIS Pro directly through a web service. Then, the data are processed and associated with the observation data, typically using the tools available in ArcGIS Pro by searching through the toolbox, clicking boxes and saving the output locally. [click]
• Then all these data might be loaded into an analytical software, such as PRESENCE or Mark. [click]
• In the software, the user selects the desired statistical analysis, typically though a point and click menu. [click]
• Finally, one would run the analysis (and rerun, and rerun) and then export the output to a local directory.

Compare Workflows

Manual

• Restricted to functions in the software

• “Black Box”

• Difficult/time-consuming to document and reproduce steps

• Must extract results into another software to visualize

Scripted

• Many custom R packages for performing most common ecological data analyses

• R packages are generally well-documented

• Your code documents your steps

• Self-contained workflow

• Let’s compare the features of this workflow to a scripted workflow [click]
• In a manual workflow, we are restricted to functions the software package. Typically, they cover many of the most commonly used statistical analyses, but there will come a time when you want to do something that it cannot do. Alterately, in a scripted workflow in R, the sky in the limit. As Jonah mentioned, there are tens of thousands of custom packages and many specific to ecological data analysis. If it doesn’t exist, you could create a new one. [click]
• Many statistical software are a black box. Do we really know what is happening under the hood? In contrast, even functions in R packages can be examined, and if you want, customized. There is complete transparency. In addition, most package are well documented with vignettes, READMEs and help files. [click]
• Describing the steps of a manual workflow can take work and time. There are a surprising number of decisions that you make when you click through software. On the other hand, the code that you write to perform an analysis is like a roadmap on what you did. It’s out there for the world to see. [click]
• Finally, to create publication quality figures and tables from results outputted from software like PRESENCE can be a chore. The raw output needs to be imported into something like Excel and manually reformatted. Each time the analysis is rerun, for example with new data, this process needs to be repeated. Alternatively, the analysis step in R is contained with the other steps of data workflow, so the the entire workflow can be rerun easily.

Witch Survey

Analysis

Let’s walk through a scripted-based analysis using our witch survey example.

Get Covariates

# Refuge boundary
source("./R/spatial_helpers.R")
tetlin <- get_refuge("Tetlin National Wildlife Refuge")

# NLCD layer
library(FedData)
get_nlcd(tetlin, label = "tetlin", year = 2016, landmass = "AK")

• Emma described the data wrangling and preservation steps for our observation data. Often, however, we need to use other people’s data as covariates in a model.
• Since witches are thought to avoid water but are attracted to forests, we want to acquire these spatial covariates to examine whether our prediction is supported.
• To do that, I created a function to get the Tetlin Refuge boundary from the FWS cadastral data layer on AGOL using web services. I run the function, called get_refuge. [click]
• Next, I want to forest and water cover within the refuge. To do this, I download the National Land Cover Database (NLCD) data using the get_nlcd function from the FedData package. [click]
• The output looks like this. A tile of NLCD data that encompasses Tetlin refuge.

Calculate Distances

library(terra)

# Calculate distance to forest
forest <- terra::segregate(nlcd, classes = 42)  # Extract the forest layer
forest <- terra::classify(forest, 
                          rcl = matrix(c(1, 0, 1, NA), 
                                       nrow = 2, 
                                       ncol = 2))  # Reclassify 0 as NA
forest <- terra::distance(forest)
forest <- project(forest, "EPSG: 4326")  # Reproject to WGS84
forest <- mask(crop(forest, ext(tetlin)), tetlin)
names(forest) <- "forest"

# Calculate distance to water
water <- terra::segregate(nlcd, classes = 11)  # Extract the water layer
water <- terra::classify(water, rcl = matrix(c(1, 0, 1, NA), 
                                             nrow = 2, 
                                             ncol = 2))  # Reclassify 0 as NA
water <- terra::distance(water)
water <- project(water, "EPSG: 4326")  # Reproject to WGS84
water <- mask(crop(water, ext(tetlin)), tetlin)
names(water) <- "water"

• But wait!
• That looked like a lot of other stuff that I don’t need. Plus, I want to look like how witches response to distance to water and forest. So I need to do a little more work.
• First, I load the terra package, which is used to work with raster data in R. [click]
• Then I run a few lines of code to extract the forest layer from the NLCD, reclassify it as 1 or 0, and then for each cell, calculate distance to the nearest forest cell. I then reproject the raster to match the Tetlin boundary, and crop/mask the distance to forest layer to the refuge. [click]
• I repeat the same steps to calculate a distance to water raster.

• Here’s the output. A raster of distance to forest on the left and distance to water on the right. Great! We’re getting somewhere. Note that they appear somewhat spatial correlated, which is something that should be addressed in an analysis, but for our simple example, we will ignore that fact.

Extract Covariates to Sites

# Required packages
library(sf)
library(terra)

# Get witch observation data from ServCat
sites <- pull_witch_data() %>% filter(year == 2024)

# Reformat for `unmarked` package
sites <- reformat(sites)

# Extract covariates to sites
sites <- data.frame(sites,
                    forest = terra::extract(forest, sites)$forest,
                    water = terra::extract(water, sites)$water)

• The next step is to extract these raster data to our observations.
• We also load the sf package, which provides general spatial data management tools [click]
• We get our witch data that Emma preserved on ServCat using her cool custom function, pull_witch_data and name it “sites”. [click]
• Next we reformat the tidy “sites” data into a wide format that is needed for analysis. For simplicity sake here, we use a custom function. [click]
• Finally, we append our sites data with the distance to forest and water values at each site. [click]
• Here’s what it looks like.

Single-Season Occupancy Model

# Required package
library(unmarked)

# Create an unmarked data frame (scaled covariates)
unmarked_df <- unmarkedFrameOccu(y = sites[,5:13], # observations
                                 siteCovs = sites[,4:5]) # covariates
sc <- scale(site_covs)  # scale them
siteCovs(unmarked_df) <- sc  # add back

# Fit single-season occupancy model
mod <- unmarked::occu(formula = ~forest ~ water + 
                                forest, 
                        data = unmarked_df[[1]])

# Look at estimates
mod@estimates

Occupancy:
            Estimate    SE      z P(>|z|)
(Intercept)   0.0923 0.213  0.433  0.6651
water         0.8643 0.337  2.568  0.0102
forest       -0.4465 0.300 -1.487  0.1370

Detection:
            Estimate    SE     z P(>|z|)
(Intercept)  -0.0507 0.115 -0.44  0.6596
forest        0.7406 0.325  2.28  0.0226

• Phew! That was a look of steps, even before running a model!
• But, the great thing is now that we have the code, we can just rerun that code whenever we get new data.
• An upfront cost and a long-term saving!
• For our witch survey, we want to estimate the occurrence of witches across Tetlin.
• A common statistical method for do this is called occupancy modeling.
• Without getting into too much detail, a great thing about this family of models is the ability to simultanuously estimate occupancy and detection probability. Given how sneaky those witches are, this could be important. We’re probably not detecting all of them.
• To do this, we load the unmarked R Package that includes functions for running occupancy models. [click]
• We then use our sites data from the previous step to create a unmarked data frame that is needed as input data for the unmarked package.
• We also center and scale our covariate data, which is often needed. [click]
• Hooray! In this step, we run the single-season occupancy model. WWe specify occupancy as a function of forest and water distance and detection as a function of forest distance. [click]
• Finally, we look at the output. [click]
• On the right is the summary of the model estimates, showing the estimates for how occupancy and detection vary with water and forest distance. While this might make sense to a biologist or biometrician, this is not a product that you would share with a decision maker. So, the next step is to translate this into something more digestible.

Summarize Results

As such, the next step in our workflow is to summarize our results.

Summarize Results

Criteria for Best Practice

• Customizable
• Updateable
• Standardized

• Like with the analytical step, there are criteria that we can use to evaluate our summarize results steps of the workflow. Here are a few examples.
• This step should be customizable. It should be flexible enough to create unique visualizations that look good and clearly communicate results.
• It should be updatable, meaning that products can be regenerated or updated efficiently and without a lot of work. In other words, reproducible.
• Finally, it should be standardized. The products should have a standard “look and feel” that is professional.

Summarize Results: Manual Workflow

Steps

1. Import results and data into Excel, ArcGIS Pro, etc.
2. Create summary tables, plots, and maps.
3. Reformat style to match document.
4. Export as images or Excel files.
5. (Rinse and repeat…)

https://www.reddit.com/r/ProgrammerHumor/comments/fiw1rw/excel/

• A typical manual workflow might look something like this: [click]
• We import our results that were outputted by our software and our data into another software. [click]
• We create our tables, plots, and maps
• We reformat them to match the document style
• We export them as images or as Excel tables
• We rinse and repeat.

Summarize Results: Compare Workflows

Manual

• Introduce human error

• Limited plotting function

• Static output

Scripted

• Self-contained workflow

• Endless options for visualizations

• Options for static, dynamic, and interactive outputs

• How does this compare to a scripted workflow for summarizing results? [click]
• The manual workflow contains many manual steps that often introduce quality issues. The R workflow is free of such errors. [click]
• The manual workflow has limited plotting functions. Excel can only do so much! Alternatively, if you can dream it, you can create it in R. [click]
• The manual workflow is generally limited to static output. Figures are images. Tables are just to look at. Alteratively, a scripted workflow allows for static and dynamic outputs. Decision makers can interactive with plots and tables.

Witch Survey

Results

Ok, back to our witch survey example. Let’s summarize some of our results!

Witch Survey Results

Occupancy (\(\psi\))

# Calculate predicted occupancy
pred <- rbind(unmarked::plotEffectsData(mod, "state", "forest"), 
              unmarked::plotEffectsData(mod, "state", "water")) |>
  mutate(covariateValue = case_when(
    covariate == "forest" ~ covariateValue * attr(sc, 'scaled:scale')[[1]] + attr(sc, 'scaled:center')[[1]],
    covariate == "water" ~ covariateValue * attr(sc, 'scaled:scale')[[2]] + attr(sc, 'scaled:center')[[2]]
  ))

• Our witch model output contained a lot of information, but it was not useable by a decision-maker.
• Our first step is to use the model output to generate some predictions of occupancy.
• The R code shown here takes our model output in “mod” and creates a table of predicted values for each site. [click]
• Since the model used scaled values of the covariates, we need to unscale them in the results to be more informative. We save the result as an object called “pred”. [click] Here’s what that table looks like.

Witch Survey Results

Detection

# Calculate predicted detection
pred_det <- unmarked::plotEffectsData(mod, "det", "forest") |>
  mutate(covariateValue = covariateValue * attr(sc, 'scaled:scale')[[1]] + attr(sc, 'scaled:center')[[1]])

This is the same step, but for predictions about detection probability. [click] - And here’s what that table looks like. - This is all well and good, but it’s still not something that you would typically hand a manager. - What we need are some visualizations of these results.

Witch Survey Results

Occupancy (\(\psi\))

library(ggplot2)

# Plot predicted values (psi)
ggplot(pred, aes(x = covariateValue, y = Predicted),
  group = covariate) +
  geom_line() +
  geom_ribbon(aes(ymin = lower, ymax = upper),
              linetype = 2,
              alpha = 0.1) +
  xlab("Distance (m)") +
  ylab("Psi") +
  theme_fws() +
  facet_grid(~covariate, scales = "free")

 

• To do that, we take the tables of predicted values for each site and create some plots
• We load the ggplot2 package, which allow us to make cool plots
• We run the ggplot function, using the table of predicted values as input data [click]
• Here’s what that looks like.
• Finally, we have something that a manager might be able to digest.
• The plot on the left clearly showed that witch occupancy at Tetlin is high overall. In forest cover, there is a 50% likelihood of witch occurrence. Yikes! As you move away from forest, you’re like likely to encounter a witch.
• Alternatively, witches are still surprisingly prevalent in water cover, but they are more likely to occur further from water.
• Our predictions of witch occurrence hold true! Thanks Google!

Witch Survey Results

Detection

# Plot predicted values (detection)
ggplot(pred, aes(x = covariateValue, 
                 y = Predicted)) +
         geom_line() +
         geom_ribbon(aes(ymin = lower, 
                         ymax = upper), 
                     linetype = 2, 
                     alpha = 0.1) +
         xlab("Distance (m)") +
         ylab("Detection (p)") +
         theme_fws()

• Now lets do that same step for predictions of witch detection.
• The code is basically the same, but the input data is the detection prediction data frame. [click]
• Here we see that the probability of detecting a witch increases with distance to forest.
• Again, the data support our a priori prediction that witches are harder to spot in forest cover.
• Sneaky witches!
• This plots are great, but our original goal was to estimate witch occurrence across Tetlin. Wouldn’t a map of these predictions be helpful?

Witch Survey Results

Maps

#' Create a leaflet map of occupancy within a refuge
#'
#' @param ras a `terra::ras` raster of psi estimates
#' @param s  an `sf::st_point` of the sites surveyed
#' @param r an `sf` multipolygon of the refuge boundary
#' @para p whether to map the predicted value of psi ("Predicted") or SEs ("SE")
#' @param h the height of the leaflet map returned
#' @param w the width of the leaflet map returned
#'
#' @return a leaflet map
#'
#' @import RColorBrewer
#' @import leaflet
#' @import terra
#' 
#' @export
#'
#' @example 
#' \dontrun{
#' create_map(ras = psi, s = sites, r = tetlin, p = "Predicted", h = 650, w = 300)
#' }

create_map <- function(ras, 
                       s, 
                       r,
                       p = "Predicted",
                       h = NULL,
                       w = NULL) {
  if (p == "Predicted") {
    x <- c(round(minmax(ras)[[1,1]],2), 
           round(minmax(ras)[[2,1]],2))
    grp <- "Psi"
    ras <- ras$Predicted
  } else if (p == "SE") {
    x <- c(round(minmax(ras)[[1,2]],2), 
           round(minmax(ras)[[2,2]],2))
    grp <-"SE"
    ras <- ras$SE
  }
  
    
  pal_rev <- colorNumeric(RColorBrewer::brewer.pal(5, "Spectral"), 
                          x, 
                          reverse = TRUE, 
                          na.color = "#00000000")
  pal <- colorNumeric(RColorBrewer::brewer.pal(5, "Spectral"), 
                      x)
  
  leaflet(height = h, width = w) |> 
    addTiles() |>
    addRasterImage(ras, 
                   colors = pal_rev, 
                   maxBytes = 10168580, 
                   opacity = 0.75, 
                   group = grp) |>
    addCircleMarkers(data = s, lat = ~Y, lng = ~X, 
                     radius = 0.5, 
                     color = "black", 
                     group = "sites") |>
    addPolygons(data = r,
                fill = FALSE,
                color = "black",
                group = "Tetlin",
                weight = 0.5) |>
    addLayersControl(overlayGroups = c(grp, 
                                       "sites", 
                                       "Tetlin"),
                     options = layersControlOptions(collapsed = FALSE)) |>
    addLegend(pal = pal,
              values = x,
              title = grp,
              labFormat = labelFormat(transform = function(x) sort(x, decreasing = TRUE))) |>
    addMiniMap(height = 100, 
               width = 100) |>
    addScaleBar()
}



base_map <- function(s, r, h = NULL, w = NULL) {
  leaflet(height = h, width = w) |> 
    addTiles() |>
    addCircleMarkers(data = s, lat = ~Y, lng = ~X, 
                     radius = 0.5, 
                     color = "black", 
                     group = "sites") |>
    addPolygons(data = r,
                fill = FALSE,
                color = "black",
                group = "Tetlin",
                weight = 0.5) |>
    addLayersControl(overlayGroups = c("sites", 
                                       "Tetlin"),
                     options = layersControlOptions(collapsed = FALSE)) |>
    addMiniMap(height = 100, 
               width = 100) |>
    addScaleBar()
}

• To do this, I wrote an R function to generate an interactive map, using a javascript plugin called leaflet.
• Luckily, there is an R package (called leaflet) that makes this pretty easy.
• What you are seeing here is the roxygen header for my function, to demostrate that we can document our functions with metadata. [click]
• The first line is the title of the function and tells everyone what it does [click]
• Next we have the list of parameters or arguments that you need to give the function. In this case, we need a raster of estimates of occupancy, point locations of our sites, a refuge boundary layer, and other stuff. [click]
• Below that, we see what this function returns. [click]
• We see what packages are required to run it [click]
• And there’s even an example of how to run it. [click]
• Below all that is the actual function

Witch Occupancy (\(\psi\))

# Generate a raster of predicted occupancy
ras <- c(water, forest)  # Combine our rasters
psi <- unmarked::predict(mod, 
                         type = "state", 
                         newdata = ras)

# Source the `create_map()` function
source("./R/create_map.R")

# Create a map
create_map(ras = psi, 
           s = sites, 
           r = tetlin, 
           h = 650,
           w = 300)

• Ok, let’s try it out. [click]
• First, we combine the water and forest rasters.
• Then we use a function in the unmarked package to predict values of occupancy at each cell [click]
• Next we source our create_map function from the last slide [click]
• And finally, we run it. [click]
• Here’s what we see. A map of the probability of witch occurrence across Tetlin Refuge. The red indicates higher probabilities, blue is lower.
• From this map, it appears that there is a hot spot of witch activity in the west corner of the refuge. We might want to let the manager know about that!

Precision of Estimates (SE)

# Source the `create_map()` function
source("./R/create_map.R")

# Import data
tetlin <- sf::st_read("data/shapefile/tetlin.shp", 
                      quiet = TRUE)
sites <- read.csv("data/csv/sites.csv")
psi <- terra::rast("data/raster/psi/psi.tif")

# Create a map
create_map(ras = psi, 
           s = sites, 
           r = tetlin, 
           p = "SE",
           h = 650,
           w = 300)

• Typically, this is all we would report, but wouldn’t it be interesting to know about the precision of our estimates and whether that varies across the refuge. We could use that to update our sampling design to increase precision of future surveys.
• Creating a map of the standard error of our occupancy estimates is straightforward. [click]
• All that we need to do is change one argument in the function and… [click]
• Our map updates to show how SEs vary across Tetlin.
• We see that our estimates at the far western boundary of the refuge are more inprecise, probably because we don’t have many sites that are really far from water. Maybe we could consider a change to our design to accomodate that.

Report

• The next step in the workflow is Reporting.

Report

Criteria for Best Practice

• Easy to update
• Clear link between the data and the report
• Reproducible

• Criteria for best practices for reporting look a lot like the rest of the steps.
• We wanting reports to be easy to update.
• We want a clear link between the data and the report.
• Finally, we want reports to be reproducible by your future self and others after you.

Report: Manual Workflow

Steps

1. Copy/paste tables and figures into Word
2. Calculate inline statistics and add into doc
3. Update formatting to look good
4. Repeat steps for PowerPoint presentation

• We are all familiar with the traditional workflow steps for generating reports. [click]
• We copy/paste the tables, figures, and maps [click]
• We calculate inline statistics and then manually type them into our Word doc
• We update the formatting until it looks good
• We rinse and repeat for other formats like PowerPoint.

Reporting in R: Quarto

• R has really grow when it comes to reporting
• Quarto was discussed in some detail during the Posit Connect presentation this week.
• Quarto is an open source scientific publishing system
• Next generation of R Markdown
• Supports multiple programming languages (R, Python, Julia, Observable)
• Can create articles, reports, presentations, websites
• Mix text with in-line code to update statistics in the text
• Can output in HTML, PDF, Word and other formats

Reporting in R: Shiny

• As many of you know, you can also create application from R
• Shiny is an R package
• Enables building interactive web applications that execute R
  • Standalone websites
  • Embed interactive charts in Quarto docs
  • Build dashboards
• Primary advantage of a Shiny app is that decision makers can interact with the data.

Witch Survey

Report

Let’s look at reporting our witch survey results.

Witch Report

Quarto Code

```{r}
---
title: "Tetlin Witch Report"
author: Jane Biologist
format: html
fig-align: center
editor: source
---


```{{r setup}}
#| echo: false
#| message: false

knitr::opts_chunk$set(warning = FALSE, 
                      echo = FALSE,
                      message = FALSE, 
                      fig.retina = 3, 
                      fig.align = "center")
library(unmarked)
library(terra)
library(tidyverse)
library(RColorBrewer)
library(sf)
library(leaflet)
```

```{{r load_data}}
#| cache: true

# Load site data
dat <- read.csv("data/csv/dat.csv")

source("R/simulate_data.R")
source("R/create_map.R")

# Scaled covariates
sc <- dat |>
    dplyr::select(forest, water) |>
    scale()

# Load site data and scale them
load("./data/rdata/unmarked_df.Rdata")
```

```{{r fit_model}}
#|cache: true

# Fit single season occupancy model
mod <- fit_model(unmarked_df)
```

## Introduction

Invasive witches have become a management concern at Tetlin National Wildlife Refuge. As such, there is a need to estimate witch occurrence within the Refuge.

## Methods

### Data Collection

We visited a sample randomly distributed sites across Tetlin Refuge. At each site, we spent one hour looking and listening for witches. We revisited each site eight times.

### Model

We estimated witch occupancy and detection using a single-season occupancy model. We used the `unmarked` R package. [blah, blah, blah]


## Results

We surveyed a total of `r nrow(dat)` sites. The average distance to water at our sites was `r round(mean(dat$water), 2)` m. The average distance to forest at our sites was `r round(mean(dat$forest), 2)` m.

```{{r}}
#| out-width: "50%"
#| fig-cap: "A map of the sites surveyed for witches, Tetlin National Wildlife Refuge, Alaska."

# Import data
tetlin <- sf::st_read("data/shapefile/tetlin.shp", 
                      quiet = TRUE)
sites <- read.csv("data/csv/sites.csv")

# Create leaflet map
base_map(sites, tetlin)
```

We observed witches on `r sum(dat[6:13])` of 800 site visits, for a naive occupancy of `r round(sum(dat[6:13])/ncell(dat[6:13]), 2)`. 

```{{r plot_psi}}
#| fig-height: 3
#| fig-cap: Occupancy of witches at Tetlin National Wildlife Refuge, Alaska, 2024.

# Calculate predicted values (unscaled)
pred <- rbind(plotEffectsData(mod, "state", "forest"), plotEffectsData(mod, "state", "water")) %>%
  mutate(covariateValue = case_when(
    covariate == "forest" ~ covariateValue * attr(sc, 'scaled:scale')[[1]] + attr(sc, 'scaled:center')[[1]],
    covariate == "water" ~ covariateValue * attr(sc, 'scaled:scale')[[2]] + attr(sc, 'scaled:center')[[2]]
  ))

# Plot predicted values (psi)
ggplot(pred, aes(x = covariateValue, y = Predicted), 
  group = covariate) + 
  geom_line() +
  geom_ribbon(aes(ymin = lower, ymax = upper), 
              linetype = 2, 
              alpha = 0.1) +
  xlab("Distance (m)") +
  ylab("Psi") +
  facet_grid(~covariate, scales = "free")
```

```

Rendered Report

• On the left is the Quarto code for our witch survey
• What I want you come away with is that this file includes the code that we already wrote, along with some text and in-line code to create summary statistics.
• We are reusing our code to generate the plots and maps.
• That all good, but you might be thinking that that report looks like garbage and the reports that I currently produce look good
• Or maybe your manager isn’t comfortable with HTML reports. We do Word docs.

Prettier Witch Report

• That’s ok. You can output reports in Quarto as PDFs or in Word
• You can create a report that has the same look and feel as your current report
• Here’s an example of that. The same information as the previous HTML report, but saves as a Word doc with the look and feel of a AK Refuge Report.

Quarto Templates

• This Quarto template is available on GitHub as an R package that you can install locally.
• Once you create your template, you can render all your Quarto reports with that look.

Share Products

• I’ll just briefly say that once you have written a report in Quarto or an application in Shiny, it is a straightforward step to making that product available as a website. You can even run it on a schedule to produce an updated report or email it regularly to a decision maker.
• This can all be done using Posit Connect, a publishing service available to FWS.
• Check out the presentation on Posit Connect for more details.

Preserve Products

• We can’t skip the preservation step.
• Although there are some options for preserving data products using web services in R, they are currently a little clunky
• Therefore, the workflow is best done manually at the moment.
• Hopefully we can make improvement to that!

Summary

• We’ve throw a lot at you and your head might be spinning
• We covered what script based workflows are.
• Some trick and tips to using them
• We hope that you have come away with an appreciate for the advantages of a script-based workflow
• If you aren’t using a script based workflow now, we hope that we have helped convince you that the time invested in moving to this approach are worth the effort.

Questions

Thank you and we will take questions if there is time.